Packets may be lost during transmission over IP networks. However, packet losses are not acceptable for many networked applications such as real-time video and audio applications. Application layer forward error correction (FEC) provides a method to recover lost media/data/source packets at the receiver/decoder. As used herein, “/” indicates alternative names for the same or like components. FEC codes are applied across source packets at the transport or application layer to generate FEC packets, which contain redundant information, at the sender/encoder or other nodes in the network. These FEC packets are transmitted to the receiver and the receiver recovers lost source packets using the redundant information in the received FEC packets.
Different coding methods and different FEC codes can be used to generate redundancy at the sender/encoder. The receiver/decoder needs to have information about coding method and parameters in order to decode and recover the lost source packets. Therefore, a signaling method and syntax are required for the sender/encoder to inform the receiver/decoder regarding FEC coding information.
Real-time transport (RTP) and User Datagram Protocol (UDP) protocols are generally used for real-time video/audio transmission/transport over/in IP networks. The payload (source packets) is encapsulated in the RTP/UDP/IP protocol stack. An RTP payload format for generic FEC packets has been defined in the RFC 2733 to enable error correction of real-time media. However, RFC 2733 limits the scope of packets used to generate the FEC payload, to 24 consecutive packets and only allows generation of one FEC packet for a block of media/source/data packets.
The Society of Motion Picture and Television Engineers (SMPTE) standard 2002-1 defines an extension to RFC 2733, which allows error correction codes to be applied to non-consecutive media packets that can be spaced over more than 24 source/media packets for burst loss recovery. However, SMPTE 2002-1 only allows Exclusive OR (XOR) encoding on a block of media packets to generate a single FEC parity packet so that only one packet loss can be corrected in an encoded block of packets. In IP networks, especially those with wireless links, packet losses may be quite high so that a FEC coding scheme with more powerful error correction capability is needed to adequately detect and correct packet losses for real-time audio and video transmitted over IP networks. Furthermore, in SMPTE 2002-1, the FEC packet signaling method and syntax do not include the total number of packets (media+FEC) for an encoded block. That is, the FEC block size is not included in a header. The sender/encoder, thus, cannot inform the receiver/decoder regarding the FEC block size information. For a more powerful FEC (N, K) code, the value of the total number of packets for an encoded block, i.e. the block size is N and the number of media packets to be protected in an encoded block is K. For example, if K media packets are encoded to generate N−K FEC packets with a Reed-Solomon (N, K) code, up to N−K losses of packets in a block of N encoded packets can be recovered. For XOR encoding, the block size N can be obtained from the number of media packets to be protected, i.e. N is always equal to K+1 since XOR encoding only generates a single FEC packet from K protected media packets and only correct one packet loss. However this is not true for a FEC (N, K) code with more powerful error correction capability. Unlike XOR encoding, the block size N for a FEC (N, K) code is an independent parameter and may not be directly related to K. N must be known at the receiver/decoder to recover the lost packets correctly. The SMPTE 2002-1 standard is not sufficient to support the signaling of the FEC (N, K) code parameters that requires the FEC block information for decoding/recovery operation.
Therefore, a new data structure/syntax for a FEC header to support more powerful FEC code, for example, RS code, for real-time video/audio transport over IP networks would be advantageous. Related to a new data structure/syntax for the FEC header, a new protection/encoding method at the sender is needed so that both the RTP header and payload of the media packets can be properly protected. Furthermore a new recovery method at the receiver is needed.